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FIELD OF THE INVENTION 
5 This invention relates generally to data communications and, more particularly, to 

data communications within a computer bus architecture. 

BACKGROUND 

The components of a computer system are typically coupled to a common bus for 

10 communicating information to one another. Various bus architectures are known in the 
prior art, and each bus architecture operates according to a communications protocol that 
defines the manner in which data transfer between components is accomplished. 

The Institute of Electrical and Electronic Engineers (IEEE) has promulgated a 
number of different bus architecture standards including IEEE standards document 1394, 

15 entitled Standard for a High Performance Serial Bus (hereinafter "IEEE 1394 Serial Bus 
Standard"). A typical serial bus having the IEEE 1394 standard architecture is comprised 
of a multiplicity of nodes that are interconnected via point-to-point links, such as cables, 
that each connect a single node of the serial bus to another node of the serial bus. Data 
packets are propagated throughout the serial bus using a number of point-to-point 

20 transactions, wherein a node that receives a packet from another node via a first point-to- 
point link retransmits the received packet via other point-to-point links. A tn^e network 
configuration and associated packet handling protocol ensures that each node receives every 
packet once. The serial bus of the IEEE 1394 Serial Bus Standard may be used as an 
alternate bus for the parallel backplane of a computer system, as a low cost peripheral bus, 

25 or as a bus bridge between architecturally compatible buses. 

A communications protocol of the IEEE 1394 Serial Bus Standards specifies two 
primary types of bus access: asynchronous access and isochronous access. Asynchronous 
access may be either "fair" or "cycle master". Cycle master access is used by nodes that 
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need the next available opportunity to transfer data. Isochronous access is used by nodes 
that require guaranteed bandwidth, for example, nodes transmitting video data. The 
transactions for each type of bus access are comprised of at least one "subaction", wherein 
a subaction is a complete one-way transfer operation. 
5 In the case of isochronous data transfers and computer systems conforming to the 

IEEE 1394 Serial Bus Standard, the prior art has attempted to manage the flow of data 
using dedicated drivers. Drivers are software entities associated with various components 
of a computer system and, among other functions, operate to configure the components and 
allow the components to be operable within the overall system. The drivers of the prior art 

10 have allowed for the transmission of video data from a digital video camera to a monitor, 
but have not allowed for real time video transmissions in a multi-tasking environment. In 
particular, the drivers of the prior art have required that a bus controller, e.g., the computer 
system's CPU, listen to a data channel at the exclusion of all other processes. As data 
arrives on the channel, it is stored in a buffer for later transmission to a frame buffer 

15 associated with a monitor. A new listen instruction must be issued for each separate 

isochronous data transmission. That is, if a single transmission corresponds to data for a 
single scan line of the monitor, for a display of five scan lines, five separate listen 
instructions are required. Because the data is being sent in real time, this system requires 
that the processor spend all of its time servicing the isochronous data transmissions, even if 

20 no data is currendy being transmitted on the bus, without servicing any other tasks. It 
would, therefore, be desirable to have a means and method for a more efficient 
management of isochronous data channels in a computer system. 

SUMMARY OF THE INVENTION 
25 A computer implemented method of managing isochronous data channels in a 

computer system is described. In one embodiment, the computer system conforms to the 
IEEE 1394 Serial Bus Standard. An isochronous channel is established within the 
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computer system and includes a linked list of buffers. The linked list of buf fers 
corresponds to display locations on a display which is part of the computer system. Once 
the linked list of buffers has been established, the computer system executes instructions 
which allow for the transmission of isochronous data across the channel. Each time a 
5 sender node, a video camera in one embodiment, is ready to transmit data, an interrupt is 
generated which causes the processor to execute instructions to manage the ilow of data 
from the sender. The processor transfers the data transmitted by the camera to a storage 
location within the linked list of buffers. Ultimately, this data is transferred to a frame 
buffer associated with a display. This interrupt driven management allows the processor to 

10 perform other tasks when no data is being transmitted over the isochronous channel. 

In another embodiment, the data transfer is DMA driven rather than interrupt 
driven. For this embodiment, the isochronous channel, including the linked list of buffers, 
is established and the process is initiated. Data transmitted by the video camera is 
transferred to memory locations within the linked list of buffers by the DMA hardware and 

15 then ultimately transferred to a frame buffer for display. 

In yet another embodiment, the central processing unit (CPU) for the computer 
system establishes an isochronous channel between a sender node and one or more receiver 
nodes, not including the CPU itself. For this embodiment, no linked list of buffers is 
required as data from the sender node is transferred directly to the receiver node. 
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BRIEF DESCRIPTION OF THE DRAWINGS 

The present invention is illustrated by way of example and not limitation in the 
figures of the accompanying drawings, in which like references indicate similar elements 
and in which: 

5 Figure 1 illustrates a computer system having a serial bus made up of a number of 

nodes; 

Figure 2 shows a display screen of a monitor of a computer system h aving an open 
window for the display of video information; 

Figure 3 shows a linked list of buffers in accordance with one embodiment; 
10 Figure 4 shows a linked list of buffers which support conditional branching 

according to one embodiment; and 

Figure 5 is a flow diagram illustrating the management of an isochronous data 
channel in a computer system according to one embodiment. 
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DETAILED DESCRIPTION 

As described herein, a method and apparatus for managing isochronous data 
channels in a computer system is provided. Figure 1 shows a computer system 5 utilizing 
a serial bus incorporating the methods and apparatus of the present invention. The serial 
5 bus may generally be constructed in accordance with the IEEE 1394 Serial Bus Standard. 

The computer system 5 of Figure 1 comprises a central processing unit (CPU) 10, a 
monitor 18, a printer 26, a video camera 32, a video cassette recorder (VCR) 36, a 
keyboard 42, and a mouse 46. The CPU 10 includes an internal hard drive 14 and a 
memory (not shown). Each of the devices of the computer system is coupled to a local 

10 node of the serial bus. In general, the device to which a node is coupled acts as the "local 
host" for that node. For example, the CPU 10 is the local host for the CPU node 12; the 
monitor 18 is the local host for the monitor node 16; the printer 26 is the local host for the 
printer node 24; the video camera 32 is the local host for the video camera node 30; the 
VCR 36 is the local host for the VCR node 34; the keyboard 42 is the local host for the 

15 keyboard node 40; the mouse 46 is the local host for the mouse node 44; and the internal 
hard drive 14 is the local host for the internal hard drive node 15. Those skilled in the art 
will appreciate that it is not always necessary for every node to have a local host, nor is it 
necessary that the local host always be powered. 

A point-to-point link such as cable 20 is used to connect two nodes to one another. 

20 CPU node 12 is coupled to internal hard drive node 15 by an internal link 21 , to monitor 
node 16 by cable 20, and to keyboard node 40 by a cable 20e. The keyboard node 40 is 
coupled to the mouse node 44 by a cable 20f. The monitor node 16 is coupled to the nodes 
of the other peripherals (not shown) by cable 20a and to the printer node 24 by cable 20b. 
The printer node 24 is coupled to the video camera node 30 by cable 20c and to the VCR 

25 node 34 by cable 20d. Each of the cables 20-20f and the internal link 21 may be 

constructed in accordance with the IEEE 1394 Serial Bus Standard and may include a first 
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differential signal pair for conducting a first signal, a second differential signal pair for 
conducting a second signal, and a pair of power lines. 

Each of the nodes 12, 15, 16, 24, 32, 34, 40 and 44 may have identical 
construction, although some of the nodes, such as mouse node 44, can be simplified 
5 because of their specific functions. Thus, the nodes can be modified to meet the needs of a 
particular local host. For example, each node may have one or more ports, the number of 
which is dependent upon its needs. For example, CPU node 12, as illustrated, has 3 ports, 
while the mouse node 44 has only 1 port. 

Referring now to Figure 2, one example of the transfer of isochronous data within 

10 computer system 5 will be described. Upon review of the entire specification, those skilled 
in the art will appreciate that this example is used to describe the methods of the present 
invention and is only one of many applications of the process described below. Figure 2 
shows the display screen of monitor 18. Within display screen 48, a window 50 is shown. 
Window 50 is implemented using programming techniques well known in the art and is 

15 used for the display of real-time video data in accordance with the methods of the present 
invention. In particular, window 50 defines the boundary within which the real-time video 
data will be displayed on display screen 48. As shown in Figure 2, window 50 consists of 
five scan lines, each having an arbitrary length L. Those skilled in the art will appreciate 
that window sizes of other dimensions could be used. 

20 In general, window 50 will be generated by an application program mnning on 

computer system 5. An example of such an application program is the QuickTime® 
program available from Apple Computer, Inc. of Cupertino, CA. In such a case, computer 
system 5 may comprise the familiar Macintosh® computer system also available from 
Apple Computer, Inc. The video data to be displayed in window 50 on display screen 48 

25 will generally be obtained from a frame buffer (not shown) associated with monitor 18. 
The techniques for displaying data stored in a frame buffer on the display screen of a 
monitor are well-known in the art. 
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In accordance with the methods of the present invention, real-time video data from 
video camera 32 is to be displayed within window 50 on display screen 48. The real-time 
video data generated by video camera 32 will comprise isochronous data packets in 
accordance with the IEEE 1394 Serial Bus Standard. Each of these isochronous data 
5 packets will include header information and payload information. The header information 
is used for routing the video data to the monitor 18 and for error detection and correction. 
The payload data comprises the video data to be displayed within window 50. 

As indicated above, the prior art has attempted to manage this flow of isochronous 
data from video camera 32 to monitor 18 as follows. Once the application program has 

10 generated window 50 within display screen 48, CPU 10 executes instructions which cause 
it to listen on one of its associated ports. These instructions are typically stored on hard 
drive 14 and are loaded into system memory (not shown) upon initialization. When the 
video camera 32 has data to transmit, the video camera node 30 generates the isochronous 
data packets and transmits them over the serial bus in accordance with the IEEE 1394 Serial 

15 Bus Standard. CPU node 12 detects the presence of the isochronous data packets and 
strips the payload information from these packets. The payload information is placed in a 
buffer in the computer memory for later transmission to the frame buffer ass<3ciated with 
monitor 18. If, for example, one transmission from video camera node 30 corresponded to 
data for a single scan line of window 50, five separate listen operations would be required 

20 to receive the video data associated with one frame to be displayed within window 50. To 
accommodate the real-time transmission nature of the video data, CPU 10 would be 
required to constantly listen to the bus for isochronous data transmissions from video 
camera node 30. That is, CPU 10 could not undertake to execute additional tasks, for 
example menu level tasks, as is common in multi-tasking environments. 

25 To overcome this problem of the prior art, the present invention uses a linked list of 

buffers such as those shown in Figure 3. Figure 3 shows a linked list of buffers which 
reside in computer memory. In keeping with the above described example, five buffers 
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comprise the linked list, one for each scan line of window 50. Each of the buffers contains 
a pointer, next, which points to the address of the following buffer in the linked list. It will 
be appreciated that these addresses correspond to memory locations within computer 
system 5. Each of the buffers also contains an address "buffer n". This address 
corresponds to the start of a scan line of window 50. The address of buffer 1 corresponds 
to the start of scan line 1 and so on. Each of the buffers in the linked list also contains a 
length parameter which corresponds to the scan line length of window 50. 

An exemplary structure of these isochronous channel buffers is shown below: 



10 typedef 
struct 

{ 



15 



20 



25 



30 



35 



}; 



struct IsochChannelBufferStruct 
IsochChannelBufferStruct 

IsochChannelBufferPtr 
Ptr 

UInt32 

pBranchChannelBuffer 



buffer 
length 



IsochChannelB uf f er 
*IsochChanne] BufferPtr; 



pBranchChannelBuffer; 

buffer 

length; 



Branch pointer to next channel 
buffer. When a branch 
condition is met, its 
corresponding branch pointer 
is used to select the next 
buffer. 

Pointer to buffer memory. 
Length of above 
buffer. 



The linked list of buffers corresponds to a particular isochronous channel. The 
isochronous channel is identified by a channel identification number (channel ID). The 
channel ID is maintained in a data record stored in the computer system 5 memory and is 
used by the various application programs and driver routines as described Ix Jow. The use 
of a common channel ID allows the interoperation of application programs, driver routines, 
and other software routines which otherwise may not be capable of operating together. 

One example of the use of a linked list of buffers according to the methods of the 
present invention as shown in Figure 3 will now be described. The example is presented 
with reference to process 100 illustrated in Figure 5 and assumes that real-time video data is 
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to be transmitted from camera 32 and displayed within a window 50 on monitor 18. To 
accommodate the transmission of the real-time video (i.e., isochronous) data, at step 102 
an application program running on computer system 5 issues instructions which cause 
CPU 10 to create an isochronous data channel identified by "channel ID". 
5 Upon receiving the instruction to create the isochronous channel ID, the CPU 10 

will execute instructions to create such a channel. This may include a channel bandwidth 
and a preferred speed. An exemplary instruction is shown below. 

10 OSStatus AllocatelsochronousChannellD ( 

IsochChannellD *pIsochChannelID, 
UInt32 bandwidth, 
UInt32 preferredSpeed); 

15 <— pIsochChannellD Returned reference to this channel for use 

in subsequent isochronous service calls. 
— > bandwidth Bandwidth required for this channel. 

— > preferredspeed Preferred speed for this channel. 

20 This instruction creates an isochronous channel ID that is used by the various isochronous 
service routines described below. The channel is initialized with the required bandwidth 
and the preferred speed. The actual channel speed may be less than the preferred speed 
depending on the maximum speed of the devices that are later attached to the channel. The 
isochronous channel is a data path between nodes which will be added as ctemnel clients as 

25 described below. 

Once a channel has been established, the application program can issue instructions 
in order to add interested clients to the isochronous channel specified by channellD. These 
clients are typically software driver routines associated with the devices, such as video 
camera 32, which take part in the display of the real-time video data to be transferred. The 

30 client software will take part in and be notified of all events associated with the given 

isochronous channel specified by the channel ID. Accordingly, at step 104, ilie application 
program instructs the driver associated with video camera 32 to send real-time video data 
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over the channel identified by "channellD" and display the data within window 50 on 
monitor 18. 

In response to the instructions issued by the application program, the camera driver 
will configure the camera 32 such that the camera 32 will transmit video data over the 
5 channel specified by "channellD". The camera driver will also establish a linked list of 
buffers, as described above, and assign the buffers to "channeUD". The linked list of 
buffers will act as storage locations for the video data to be transmitted by cttmera 32. 

An exemplary instruction for adding clients to "channellD" is shown below 

10 OSStatus AddlsochronousChannelClient ( 

IsochChannellD isochChannellD, 
DriverlD driverlD, 
B oolean clientlsTalker) ; 

15 — > isochChannellD Reference to the isochronous 

channel to add the given client to. 
— > driverlD Reference to the driver client to 

add to the given channel. 
— > clientlsTalker If the given client will be a sender 

20 node (i.e., a node that will be "doing 

the talking" in IEEE 1394 parlance) 
this should be set to true. Otherwise 
it should be set to false (i.e., if the 
node will be a listener). 

25 This instruction adds the driver specified by "DriverlD" as a client to the isochronous 
channel specified by IsochChannellD". The client will be called to perform its role in 
initializing, starting and stopping the given isochronous channel. The client will also be 
informed of all channel events such as bus resets. 

For the example of Figure 5, at step 106 the video camera driver adds the video 

30 camera as a sender client for the isochronous channel specified by channellD. Then, at step 
108, the camera is added as a receiver (listener) client of the channel specified by 
channellD. The camera driver is added as both a talker and a listener so that the driver can 
both start the camera sending data and set up the CPU to receive the data for display. 



-11- 



04860.P1885 



'0 



)1 10 



1^ 



30 



35 



Next, at step 1 10, the camera driver sets up the linked list of buffers described 

above. Once this is accomplished, a port on CPU node 12 can be set to listen to the 

isochronous channel. An exemplary routine for this procedure is shown below. 

OSStatus AllocateLocallsochronousPort ( 

ReferencelD referencelD, 
IsochPortID *pIsochPortID, 
UInt32 channelNum, 
UInt32 speed, 
Boolean talking); 



--> referencelD Reference used to indicate which node to 

allocate port on. 

<— pIsochPortID Returned reference to this port for use in 

subsequent port service calls. 
15 --> channelNum Channel number for this port. 

--> speed Speed for this port. 

— > talking If false, allocate a port for liste nting, 

otherwise allocate a port for talking. 

Figure 5 illustrates the case where a user also wishes to record video data 

20 transmitted by camera 32 for a later playback. To accomodate this, at step 1 12 the 

application program issues instructions to establish the VCR driver as a recei ver client of 

the channel specified by "channellD". In response, the VCR driver adds itself as a channel 

client at step 114. 

Once all of the clients have been added to the isochronous channel specified by 
25 channel ID, a start instruction can be issued at step 116. This instruction, an example of 
which is given below, calls all of the given isochronous channels clients (i.e., the driver 
software associated with the various devices) to start the given isochronous channel. Each 
listening client is first instructed to listen to the channel. Once all of the listeners are ready, 
the sender client is instructed to start the transmission of data. 



OSStatus StartlsochronousChannel ( 

IsochChannellD isochChannellD); 

--> isochChannellD Reference to the isochronous channel to start. 



As shown in Figure 5 then, once the start command is issued by the application 
program, a service routine calls each channel client at step 118. At step 120, the camera 
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driver configures the local port on CPU node 12 to start listenting to the isoclironous 

channel specified by channellD. An exemplary instruction is shown below. 

OSStatus StartLocallsochronousPort ( 

IsochPortActionParamsPtr pIsochPortActionParams); 

5 

<--> pIsochPortActionParams Pointer to parameter block. 

--> controlHags Flags used to control the request. 

<-- status Current status of request. 

-> completionProc Procedure to call upon completion of 

l * u ^ 10 request. 

--> completionProcData Data to be used by completionProc. 

— > isochPortID Reference to local port to start. 

— > pIsochChannelBuffer Isochronous channel buffer chain to 

talk/listen into/from. 

15 --> actionSync Sync event to start on. 



This instruction causes the local port specified by isochPortID to start listening (for the 
example of Figure 5) on its isochronous channel using the buffer chain previously 
established and specified by pIsochChannelBuffer (i.e., the starting address of Buffer 1 in 
Figure 3). 

20 Similarly, at step 122 the VCR driver programs the VCR 36 to start listening to the 

isochronous channel specified by channellD. Once this is completed, the service routine 
issues instructions telling the camera driver to program camera 32 to start sending data over 
the isochrounous channel. At step 126, the camera driver does so. 

At this point, CPU 10 may continue with other instructions as indicated by step 

25 130. For example, CPU 10 may respond to menu level instructions initiated by a user or 
execute commands for a selected foreground application. When video camera 32 transmits 
data on the isochronous channel specified by a channel ID, the CPU receiving the data 
generates an interrupt. The interrupt is recognized at step 128 and procedure 100 moves to 
step 132 where the interrupt causes the CPU 10 to execute instructions which transfer the 

30 incoming isochronous data into an appropriate buffer within the linked list. The CPU 10 
then returns from the interrupt to complete or continue with any tasks. For the second 
embodiment described above, a DMA transfer is initiated to transfer the data without 
interrupting the CPU 10. Subsequently, data is transferred from the buffers which 
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comprise the linked list to a frame buffer associated with monitor 18 for eventual display on 
display screen 48 within window 50. This process continues until an isochronous channel 
stop instruction is issued. 

Stopping the transmission of isochronous data is similar to the starting process. 
5 This time, however, a stop command is issued which calls all of the given channels clients 
as follows. First, the stop command calls the sending client to stop sending data on the 
channel. Once the sender stops, the stop command calls each of the listening; clients to stop 
listening. 

Those skilled in the art will recognize that the simple linked list configuration 

10 shown in Figure 3 is subject to certain errors. For example, the linked list shown in Figure 
3 has buffer 1 corresponding to scan line 1 of window 50, buffer 2 corresponding to scan 
line 2 of window 50, and so on. Under normal operating conditions, the real-time video 
data intended for the top of the frame in window 50 will be stored in buffer 1, 
corresponding to scan line 1. Typically, the top-of-frame (ToF) data is tagged to indicate it 

15 as such. However, when errors in the video data stream occur, for example a garbled 

transmission, using the linked list approach of Figure 3 it is possible that one line worth of 
data could be missed and, for example, the top-of-frame data could then be placed in the 
buffer corresponding to scan line 5. In such a case, the ultimate picture displayed within 
window 50 would appear with the top-of-frame data at the bottom of the screen instead of 

20 the top of the screen. Such a condition is generally unacceptable. 

To account for these types of errors, a more complex linked list of buffers is used. 
This more complex scheme is shown in Figure 4. The linked list of buffers shown in 
Figure 4 support conditional branching. That is, the linked list contains pointers which do 
not necessarily correspond to the succeeding buffer in the chain. Instead, the linked list 

25 supports pointers (nextl) which point back to the first address of the first buiffer in the 
linked list (or, potentially, any other buffer, as desired and depending upon the branch 
condition described below). Associated with the pointer nextl is a data field condl. The 
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data field condl may, for example, correspond to a top-of-frame indication. Thus, when 
real-time video data is received over the isochronous channel, if the data indicates that it is 
meant for the top-of-frame in window 50, the linked list will point to the starting address of 
the buffer associated with scan line 1. In this way, top-of-frame data will always be 
5 displayed at the top of window 50. 

Where the video data received does not have a top-of-frame indication, the linked 
list will point to the next buffer in the chain. In this way, the situation described above 
where the data is displayed with the top-of-frame at the bottom of the window is avoided. 
Those skilled in the art will appreciate that other branching conditions, such as branch on 
10 fill or branch on synch, can also be implemented. 



An exemplary structure of these isochronous channel buffers is shown below: 



typedef struct IsohChannelBufferStruct 



IsochChannelB uff er 
*IsochChannelBufferPtr; 



15 



structlsochChannelBufferStruct 



25 



20 



30 



IsochChannelB uf ferPtr 
IsochChannelB uf ferPtr 
Ptr 



UInt32 
UInt32 
UInt32 
UInt32 
UInt32 
UInt32 
UInt32 
UInt32 
UInt32 



IsochChannelHandlerProcPtr 
UInt32 



pB ranch IChannelBuffer; 

pBranch2ChannelBuffer; 

buffer; 

length; 

offset; 

status; 

branchlConditionals; 

branchlData; 

branchlState; 

branch2Conditionals; 

branch2Data; 

branch2State; 

isochChannelHandler; 

isochChannelHandlerD ata; 



}; 



35 



pBranch2ChannelBuffer 



pBranch IChannelBuffer 



Branch 1 pointer to next channel 
buffer. When a branch condition is 
met, its corresponding branch pointer 
is used to select the next buffer. If 
both branch conditions are met 
simultaneously, branch 1 will take 
precedence. 

Branch2 pointer to next channel 



40 



buffer. 



buffer 
length 
offset 



Pointer to buffer memory. 
Length of above buffer. 
Current offset into above buffer. 
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status 

branch 1 Conditionals 
branchlData 

branch 1 State 

branch2Conditionals 

branch2Data 

branch2State 
isochChannelHandler 

isochChannelHandlerData 



Status of this buffer. 

Conditions to meet to fcike branch 1. 

Data to use to further specify 

branch 1 conditions. 

Current state of branch 1 conditions. 

Conditions to meet to tiike branch2. 

Data to use to take branch2 

conditions. 

Current state of branch2 conditions. 
Handler to call when a branch is 
taken. 

Data for above handler to use for its 
own purposes. 



15 The channel handler field within each of the buffers of the linked list provides a 

means of accommodating data conversion. For example, video camera 32 may transmit 
video data in YUV format. However, monitor 18 may require the data in RGB format. 
Thus, a conversion would be required to change the YUV data to RGB data before display. 
The channel handler can be a set of software instructions to be called whenever a particular 

20 channel branch is taken so that after a buffer is filled, the data stored in the buffer can be 
converted from YUV data to RGB data for display. Thus, the channel handler would 
specify an address which corresponds to instructions for performing a conversion routine. 

Another example of when such a channel handler may be required is when 
compressed data is being transmitted over the serial bus. Before display, the data would 

25 need to be decompressed. The channel handler routine could be used to decompress the 
data in the manner described for the YUV to RGB translation described above. Other 
examples of the use of such channel handlers will be apparent to those skilled in the art. 

Thus far, the present invention has been described with the assumption that the 
CPU 10 will manipulate data transferred across the isochronous channel (i.e., the CPU 

30 transfers the data to the linked list of buffers within system memory for later transfer to a 
frame buffer). This need not, however, be the case. In other embodiments, the CPU 10 
can establish the isochronous channel without becoming part of the channel. For example, 
in the situation where a user wishes to record video data produced by camera 32 on a video 
cassette, the isochronoucs channel can be established between only video camera 32 and 
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VCR 36. In this example, one driver might be associated with the video camera 32 and a 
second driver might be associated with the VCR 36. The camera driver would establish the 
channel ID and add the camera 32 as a sender client in the manner described above. The 
camera driver would then call the VCR driver and would pass a reference to the channel ID. 
5 The VCR driver would add the VCR 36 as a listener client as described above. Once all of 
the clients have been added to the channel, the "start" instruction can be issued as described 
above. No linked list of buffers is required because the VCR 36 can record the video data 
directly (it need not be in frames). Now, isochronous data (i.e., video data) will be 
transmitted from the camera 32 to the VCR 36 without interrupting the CPU 10 (which is 
10 not a client of the isochronous channel). Those skilled in the art will appreciate that any 

number of clients can be added to the isochronous channel in this fashion to accomodate the 
required data transfer. 



15 appreciate that a similar configuration of buffers could be used at the sending node. In 

such an embodiment, isochronous data would be stored in a linked list of buffers similar to 
that described above and transmitted over the isochronous channel as network conditions 
permit 



20 computer system has been described. In the foregoing specification, the invention has been 
described with reference to specific exemplary embodiments thereof. It will, however, be 
appreciated by those skilled in the art that various modifications and changes may be made 
thereto without departing from the broader spirit and scope of the invention zis set forth in 
the appended claims. The specification and drawings are accordingly, to be regarded in an 

25 illustrative rather than a restrictive sense. 



Although the methods of the present invention have been described with reference 



to the use of a linked list of buffers at the receiving node, those skilled in the /fit will 




Thus a system and method for managing isochronous data channels within a 
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